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STRS Architecture 
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• STRS Project Management Considerations 
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STRS Background 
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STRS Goals and Objectives 



• Applicable to space and ground missions of varying 
complexity 

• Decrease the development time and cost of deployed 
capabilities 

• Increase the reliability of deployed radios 

• Accommodate advances in technology with minimal 
rework 

• Adaptable to evolving requirements 

• Enable interoperability with existing radio assets 

• Leverage existing or developing standards, resources, 
and experience 

• Maintain vendor independence 

• Enable waveform portability between compliant platforms 

• Enable cognitive radio concepts 
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STRS Project Benefit 
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STRS Benefits 

• Software Defined Radios (SDRs) accommodate 
advances in SDR capabilities with minimal rework 

- Adaptable to evolving requirements 

- Allows software modification later in development cycle or 
even after deployment 

- Enables cognitive radio concepts 

- SDRs are common in commercial and military industries 

• SDRs allow encapsulation of functionality. 

- Allows vendors to work on different parts of the radio at once 

- Allows updates to one part not to affect the other parts of the 
radio 

- Promotes multiple vendors and vendor independence 
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STRS Benefit 

• Increase the reliability and decrease the development 
time and cost of deployed SDR capabilities 

- Leverage existing or developing standards, resources, and 
experience 

- Enable waveform portability between compliant SDR 
platforms 

- May obtain artifacts from STRS Application Repository for 
porting or reuse 

- Leverage software and firmware design and implementation 
processes and tools to lower risk and increase reliability 

- Gain knowledge from past experience i.e. lessons learned 

- Gain experience that is directly transferable 

• Interoperable with existing radios 
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STRS Project Burden 
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STRS Project Burden 

• A general purpose processor is required in the radio 

• STRS API is required to promote portability 

• Configuration files are required to define initial state 

• STRS compliance testing is required 

• Documentation is required 

- High level system or component software model 

- Application firmware external interfaces 

- Hardware Interface Description (HID) 

- Hardware Abstraction Layer (HAL) 

- STRS application behavior 

- Application development environment and tool suite 

- Test plan and results documentation 

- Identification of Flight Software Development Standards used 
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Simplified STRS Diagram 
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STRS Layer Cake Diagram 
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STRS Compliance 
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STRS Project Management 

Considerations 
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STRS Application Life Cycle 
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STRS Considerations 



The mission/project should define the responsible 
organizations corresponding to the STRS roles 
specified in the STRS Architecture Standard and each 
organization’s deliverables accordingly. 

• STRS Roles 

- Platform Provider 

- Application (Waveform) Developer 

- Integrator 

• Additional roles to be identified 

(provided by STRS team at GRC) 

- STRS Liaison 

- STRS Repository Manager 

- STRS Compliance Testing 
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STRS Roles & Responsibilities 
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STRS Project Management 

Considerations 

Detail 


(stop here if only overview) 
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STRS Considerations (1) 



1 The mission/project should require any hardware 
and software developers to use the STRS 
Architecture Standard with a specified version. 


• Some entity has to actually require that STRS shall be used on 
specific radios for a specific mission. 

• When the STRS Architecture Standard becomes a NASA 
Standard, NASA-STD-4009, this version will become the 
standard to be used on all NASA radios. 

• However, currently STRS version 1 .02.1 is the latest approved 
version. 
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STRS Considerations (2) 

3 The mission/project should review the 

goals/objectives and level 1 requirements and 
decide which operational capabilities are required. 

• Most of the requirements at level 1 are stated in the form “STRS 
architecture shall allow” but that doesn’t means that every STRS 
implementation must have that operational capability. 

• Examples: 

Scalability, flexibility, reliability, extensibility, adaptability, 
interoperability, reconfigurability, reprogrammability, 

Built-in testing and status reporting 
Simultaneous operations 
See also 7 on the next slide 
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STRS Considerations (3) 

7 The mission/project should specify whether multiple 
STRS applications are necessary, whether they may 
be simultaneous, etc. 

• See also 3 on the previous slide. 



www.nasa.gov 20 


National Aeronautics and Space Administration 

STRS Considerations (4) 



4 The mission/project should provide resources for 
collection, identification, and submission of artifacts 
to NASA’s STRS Application Repository. 


• The STRS Application Repository is designed to support 
application software and firmware identification and reuse. 

• The STRS Application Repository allows for survival of 
knowledge and artifacts after the project ends. 

• The STRS Application Repository supports porting of software, 
firmware, and/or design. 

• The mission/project should negotiate agreements that require 
submission of artifacts to the STRS Application repository and 
allow their subsequent release with appropriate restrictions. 
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STRS Considerations (5) 

5 The mission/project should provide resources for 
capturing lessons learned. 

• Need to address deviations and non-compliances. 

• Need to provide lessons learned to STRS team primarily via the 
STRS website. The URL for STRS lessons learned is: 

https://strs.arc.nasa.aov/repositorv/forms/lessons-learned/ 



www.nasa.gov 22 


National Aeronautics and Space Administration 


STRS Considerations (6) 

6 The mission/project should provide resources for 
addressing STRS non-compliances and responding 
to STRS-related questions and comments. 

• The mission/project should specify how to address non- 
compliances and issue waivers. 
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STRS Considerations (7) 



12 The mission/project should determine whether there 
are one or more external command sources for the 
radio and whether the commands are parsed the 
same way or differently. 


• Command and Control from ground station may be direct to the 
radio or indirect through another radio. 

• Testing may use different ports. 
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STRS Considerations (8) 



8 The mission/project should determine what external 
commands are needed to exercise what features of 
the STRS architecture. 


• The mission/project should determine whether to standardize 
portions of the external interface command dictionary when 
multiple radios are involved. 

• Alternately, there might be a standardized operations diagram 
that includes the STRS applications. 

• The mission/project should determine requirements for built-in- 
tests, externally commanded tests, and externally queryable 
information. 
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STRS Considerations (9) 



9 The mission/project should decide whether 
synchronization with external clocks or timers is 
necessary, for what purpose, and at what frequency. 


• The reason is to help determine whether having a low accuracy 
clock in the GPP is sufficient or whether a high accuracy clock is 
needed. 

• The project should define STRS_Synch functionality based on 
the mission needs. 
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STRS Considerations (10) 



10 The mission/project should specify whether there 
are operator requirements. 


• Most radios in space are autonomous and have no co-located 
user. 

• Most radios in space are commanded from the ground or other 
satellite. 
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STRS Considerations (11) 



1 1 The mission/project should specify whether there 
are data flow requirements. 


• Data rate (internal and external). 

• Quality of Service (QoS). 

• Path & end points. 

• Antenna requirements. 
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STRS Considerations (12) 

13 The mission/project should determine how errors are 
recognized and processed. 

• Is there a watchdog timer? If so, there are two sets of 
requirements needed: one for the radio to create a heartbeat 
signal and one for the flight computer or other component used 
to monitor the heartbeat signal and reboot the radio if the 
heartbeat dies. 

• It is up to the mission/project to define whether there are 
alternate ways of rebooting under different circumstances. 
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STRS Considerations (13) 

15 The mission/project should check whether the 
required functionality already exists in the STRS 
Application Repository. 

• Much savings is from reuse and porting. 
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STRS Considerations (14) 



16 The mission/project should identify required data 
and control parameters for each STRS application 
as well as the STRS infrastructure. 


• The required configurable parameters and queryable 
parameters need to be specified. 

• For example, if the mission would want the waveform 
applications to be created to process a range of data rates, that 
would have to be required up front with test considerations for 
specific data rates. 
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STRS Considerations (15) 



17 The mission/project should determine whether 
telemetry is provided using a polling technique 
where the data is provided only upon request or sent 
at a periodic rate. 


• This should correspond to whether the telemetry is created by 
the OE using STRS_Query or by the application using 
STRS_Log? 

• The OE should handle any timed telemetry to avoid every 
application vying for time. 

• The application should obtain the data, appropriate for 
telemetry. There should be requirements about how data is 
formatted. 
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STRS Considerations (16) 

18 The mission/project should determine whether a 
service would be needed to monitor the values of 
temperature, pointing angle, etc. against some limits 
and what action should be taken at each limit. 

• A value such as the temperature could signal the need for an 
action such as heating or cooling to avoid problems. In some 
cases, it would signal the need for a partial shutdown to lessen 
power consumption. 

• Additional monitoring would be required if cognitive capabilities 
were desired. 
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STRS Considerations (17) 



19 The mission/project should determine the software 
classification described in NASA Procedural 
Requirements (NPR) 7150.2 and follow the 
corresponding requirements for software 
management, engineering, support, test, and 
documentation, or the equivalent. 


14 The mission/project should determine what level of 
testing is to be performed by whom and the 
corresponding reporting requirements. 
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